Dropping in to note that this would be incredible useful for bdk_kyoto. It is likely that a LocalChain generic over Header would allow the CBF system to simply use the LocalChain the chain backend, and the persistence may be shared between a Wallet and the node.

+1 for this feature, bdk_floresta could share persistence with bdk_wallet as well.

At a high level I think the API would be cleaner if the generic methods had the simpler names (new, push, extend, insert) and the old methods were renamed push_block_id, extend_block_ids, etc.

CheckPoint::data method can be two methods:

fn data_ref(&self) -> &B {}

fn data(&self) -> B where B: Clone {} // or Copy

LocalChain should have more of a unified interface. Most of the methods should be generic and the only methods under impl LocalChain<BlockHash> {} should be the ones that only make sense in the old design (from_genesis_hash, insert_block, etc). Having two versions of apply_changeset and _check_changeset_is_applied isn't very helpful.

Remaining questions:

1. Will it be possible to migrate an existing sqlite database to one that persists a local chain of headers, or will it require adding a new SQL table?
2. Are there plans to enable syncing a local chain of headers using bdk_electrum / esplora?

Edit: I added my review with some API suggestions in LagginTimes#5

@LagginTimes is this ready to review again? Remember to mark it as so and request reviewers, otherwise no one will know about it.

What was the discussion around breaking changes? Were we okay to break the API?

What was the discussion around breaking changes? Were we okay to break the API?

Iirc the consensus was for this to be a breaking change to be a cleaner API.